A plug-in is a special kind of software component that adds specific capacities to a larger software application. A plug-in typically cannot be executed alone, but instead relies on the larger software application, which is often referred to as the “host application program.” If the plug-in is supported by the software application, it enables customizing the functionality of an application. Plug-ins have been widely used due to their compactness, effectiveness, and power to perform a function that the software applications themselves do not perform. For example, plug-ins are commonly used in web browsers to process specific types of files. The browser can directly invoke the plug-ins to play video, scan for viruses, and display new file types. Some plug-ins include a Dynamic-Link Library (DLL).
To perform functions that a hosting program cannot perform, a plug-in is often required to access a service available from the hosting program. FIG. 1 is a schematic diagram illustrating how a plug-in operates. As shown in the figure, the host application provides services which the plug-in can use, including a mechanism for plug-ins to register themselves with the host application program and a protocol for the exchange of data with plug-ins. Plug-ins depend on the services provided by the host application programs and do not usually work by themselves. On the contrary, the host application operates independently of the plug-ins, making it possible for end-users to add and update plug-ins dynamically without needing to make changes to the host application. Open Application Programming Interfaces (APIs) provide a standard interface allowing third parties to create plug-ins that interact with the host application. Host application programs often provide Software Development Kits (SDKs) that are accessible to plug-in developers.
Since plug-ins may be developed by plug-in developers who may or may not be trusted by the host application programs, security measures have to be taken by the hosting application programs.
One of the conventional security measures is to close all the sensitive interfaces. For example, if a host application program is an instant messaging application program, it will not open the interfaces that access contact information, account information, transaction entries, lists of commodities, etc. Therefore, this approach to plug-in privilege control substantially limits the host application programs' openness, as well as the quantity and functionalities of plug-ins that can be developed for the corresponding program.
Another conventional security measure uses a matching scheme of service levels and plug-in levels to control plug-in privilege. For example, both the services and plug-ins of the hosting application are assigned with respective levels arranged in descending orders, and correspondence relationships between the service levels and the plug-in levels are established to determine which level(s) of services are accessible to the respective levels of plug-ins. Then, when a specific service is requested for a plug-in, the service level of the service is determined as well as whether the service level is appropriate for the plug-in requested. Access to the service by the plug-in is allowed or disabled according to the result of the matching. This plug-in privilege control approach not only performs the intended security management and control for plug-ins, but also offers different services to different plug-in developers while taking security into consideration.
However, both of the conventional plug-in privilege control approaches may have some drawbacks.
The precision control of the conventional approaches may not meet the requirement of some host applications and unwanted security compromises may have to be made. Conventionally, the existing service levels are divided into two levels, “high” and “low,” and the plug-ins are also divided into two levels, “normal” and “trusted.” Services with both the “high” and “low” levels are accessible to plug-ins with the “trusted” level. Only the “low” level of services may be accessible to plug-ins with the “normal” level. As a result, respective services at the same service level are either accessible or inaccessible to a plug-in at a specific level. Thus, it is difficult to attain the granularity of precision control on the privilege of plug-ins. Because of the simple two-level schemes of services and plug-ins, the conventional approaches may lead to unwanted security leakage. Since the accessibility of plug-ins is only in two states, accessible or inaccessible, at one of the two service levels, in order to allow a plug-in to function at one service level, all of the services at this particular level are open to the plug-in. If a reviewing engineer who assigns the plug-in levels does not consider thoroughly all the possibilities of security leaks, a plug-in may be able to access some services that it should not be allowed to access. Thus, the security of the host application programs may be compromised.